[Security Solution] Randomize task schedules when bulk scheduling by sdesalas · Pull Request #269991 · elastic/kibana

sdesalas · 2026-05-19T15:58:36Z

Resolves: #195136
Related to: #264893
Related to: #269340

Summary

TaskScheduling.bulkSchedule previously sent every task to the store with no runAt, which caused the store to default them all to "now". When a caller bulk-scheduled many recurring tasks at once, the polling queue was flooded with simultaneous claims.

This PR brings bulkSchedule in line with bulkEnable (see #172742): the first task in the batch still runs immediately, but subsequent enabled recurring tasks are scheduled with a randomized runAt, evenly distributed up to 5 minutes in the future. Ad-hoc tasks (no schedule.interval) and disabled tasks are left untouched and run immediately as before.

This also helps unblock upcoming work on RulesClient.bulkCreate (#264893), where a single API call may schedule a large number of detection-rule tasks at once.

Whats included

The existing randomlyOffsetRunTimestamp() helper is replaced by a smaller pure helper addJitter() that returns { runAt, scheduledAt } - or undefined when no interval is supplied - so callers control the spread.
bulkSchedule map callback now receives the index i and uses addJitter() when enabled && i > 0.
bulkEnable's behavior continues exactly the same with the i > 0 branch using the shared addJitter() helper.

How to test

Important

There is no easy way to test TM bulkSchedule() randomizing without v2 alerting. Because of this, the test below only covers task randomizing under bulkEnable(). If you apply debugging here, you will notice that enabling detection rules in bulk uses bulkSchedule() under the hood, but it does so in enabled: false state. In other words, no jitter will get applied until the following pass. This is expected, what the test below does primarily is to verify that existing behavior is unaffected. The changes to behavior in bulkSchedule(enabled:true) will become more meaningful with upcoming work on alerting v2 and RulesClient.bulkCreate.

Start ES + Kibana from this branch. Make sure you have a clean ES with no rules.
In Kibana, navigate to Security → Rules → Detection rules (SIEM) and click Add Elastic Rules to install the prebuilt detection rule set (~1850 rules). Leave them disabled.

Note: This is a good time to place some breakpoints if you're debugging locally.

Go back to the rules management screen. Under "Installed Rules" click the checkbox to select first 20 rules then Bulk actions > Enable. You should see a message saying "Successfully enabled 20 rules"
Verify the runAt / scheduledAt distribution using check-task-runtime.sh:

$ ./check-task-runtime.sh

Or if you are using ports different to the standard 5601 and 9200

$ KIBANA_DEV_PORT=5606 ES_DEV_PORT=9205 ./check-task-runtime.sh

Expected output: counts match, and the first-20 task timestamps are spread across several minutes rather than all stamped with the same "now":

starting..
KIBANA_URL=http://localhost:5601/kbn
ES_URL=http://localhost:9200
1. 2. 3. 4. 5. 6.
rules:           1850
rules_enabled:   20
tasks:           20
tasks_enabled:   20
api_key_owner:   20
apiKey present:  20

first 20 tasks:
taskType                  status  enabled  runAt                     scheduledAt
alerting:siem.queryRule   idle    true     2026-05-19T16:20:08.323Z  2026-05-19T16:20:08.323Z
alerting:siem.queryRule   idle    true     2026-05-19T16:21:28.689Z  2026-05-19T16:21:28.689Z
alerting:siem.eqlRule     idle    true     2026-05-19T16:21:05.927Z  2026-05-19T16:21:05.927Z
alerting:siem.queryRule   idle    true     2026-05-19T16:20:53.163Z  2026-05-19T16:20:53.163Z
alerting:siem.queryRule   idle    true     2026-05-19T16:23:30.562Z  2026-05-19T16:23:30.562Z
alerting:siem.esqlRule    idle    true     2026-05-19T16:23:45.295Z  2026-05-19T16:23:45.295Z
...

For every task, runAt should equal its matching scheduledAt. The timestamps should be distributed across the configured jitter window (min(rule interval, 5m)) - confirming jitter is applied per-task. On main without this PR, every task's runAt collapses to the same value.

Callers of `bulkSchedule`

For reference, the production callers of TaskScheduling.bulkSchedule and whether they exercise the new jitter:

Caller	What it schedules	Hits the new jitter?
`alerting_v2/.../rules_client.bulkEnableRules`	enabled, recurring (`schedule.interval`, `enabled: true`)	Yes — primary path exercised by the manual test above
`alerting/.../bulk_enable_rules.ts` (legacy)	recurring but `enabled: false` — the comment in that file explicitly says "we create the task as disabled, taskManager.bulkEnable will enable them by randomising their schedule datetime"	No (jitter applied later by `bulkEnable`)
`workflows_execution_engine/server/plugin.ts`	enabled but ad-hoc (no `schedule`)	No (ad-hoc — runs immediately, correct)
`actions/create_execute_function.ts`	ad-hoc action tasks	No
`actions/create_unsecured_execute_function.ts`	ad-hoc action tasks	No
`alerting/.../backfill_client.ts`	variable is literally `adHocTasksToSchedule`	No

Of these, only the alerting_v2 bulkEnableRules path schedules enabled recurring tasks in bulk, so it is the only caller whose runtime behavior changes with this PR.

Release note

skip

Checklist

Unit or functional tests were updated or added to match the most common scenarios

Identify risks

Behavior change is scoped to recurring tasks at i > 0; single-task bulkSchedule calls and ad-hoc tasks retain the existing "run now" semantics.
The bulkEnable path is unchanged in semantics; only the helper signature changed.

Resolves: elastic#195136 Bring `TaskScheduling.bulkSchedule` in line with `bulkEnable`: the first task in a batch still runs immediately, but subsequent enabled recurring tasks are scheduled with a randomized `runAt` between 1ms and `min(interval, 5m)` from "now". Ad-hoc and disabled tasks are left untouched and run immediately as before. This prevents the polling queue from being flooded with simultaneous claims when many recurring tasks are bulk-scheduled in one call. `randomlyOffsetRunTimestamp` is replaced by a smaller pure helper `addJitter(interval?: string)` that returns just the timing fields, and the `bulkEnable` `i > 0` branch uses it too. Co-authored-by: Cursor <cursoragent@cursor.com>

infra-vault-gh-plugin-prod · 2026-05-20T10:12:56Z

Pinging @elastic/response-ops (Team:ResponseOps)

infra-vault-gh-plugin-prod · 2026-05-20T10:12:57Z

Pinging @elastic/security-detections-response (Team:Detections and Resp)

infra-vault-gh-plugin-prod · 2026-05-20T10:12:59Z

Pinging @elastic/security-solution (Team: SecuritySolution)

infra-vault-gh-plugin-prod · 2026-05-20T10:13:01Z

Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management)

darnautov

LGTM

darnautov · 2026-05-20T15:24:40Z

+        const enabled = modifiedTask.enabled ?? true;
+        // Run the first task now. Run all other tasks a random number of ms in the future,
+        // with a maximum of 5 minutes or the task interval, whichever is smaller.
+        const runAt = enabled && i > 0 ? addJitter(modifiedTask.schedule?.interval) ?? {} : {};


nit: since the variable contain an object with more fields than runAt - { runAt: Date, scheduledAt: Date } shall we name it jitterSchedule or something similar?

Thanks @darnautov, addressed in 08379a0

I went with var name scheduling to cover all situations, jittering and no jittering.

darnautov · 2026-05-20T15:29:21Z

        });
+        const enabled = modifiedTask.enabled ?? true;
+        // Run the first task now. Run all other tasks a random number of ms in the future,
+        // with a maximum of 5 minutes or the task interval, whichever is smaller.


nit: I guess this comment was carried over from bulkEnable, but bulkSchedule doesn't actually set runAt: new Date() for i == 0, it just spreads {} and lets the store default to now.
Could we either adjsut the wording to match what's happening, or mirror bulkEnable and set runAt: new Date(), scheduledAt: new Date() explicitly for i == 0?
I think it'd be easier to have consistent logic for both methods

Thanks @darnautov, addressed in 08379a0

Logic is the same now across bulkEnable and bulkSchedule. You're right the comment was not clear that the magic was happening inside the store. Seeing the dates set explicitly makes this clear on this end.

Also added this change to make sure that adhoc tasks are set with a date explicitly (to run now).

kibanamachine · 2026-05-20T17:37:59Z

💛 Build succeeded, but was flaky

Buildkite Build
Commit: ae89883

Failed CI Steps

Test Failures

[job] [logs] Scout Lane #35 - serverless-search / workflows_ui / local-serverless-search - Workflow composition - sync: waits for child workflow and completes with correct step count
[job] [logs] Scout Lane #8 - stateful-classic / default / local-stateful-classic - Entity analytics management page - Privileges - should show privileges callout and disable switch for user without risk engine privileges

Metrics [docs]

✅ unchanged

History

💛 Build #445240 was flaky 7cde863
💛 Build #445149 was flaky fba596b

cc @sdesalas

…astic#269991) **Resolves: elastic#195136** **Related to: elastic#264893** **Related to: elastic#269340** ## Summary `TaskScheduling.bulkSchedule` previously sent every task to the store with no `runAt`, which caused the store to default them all to "now". When a caller bulk-scheduled many recurring tasks at once, the polling queue was flooded with [simultaneous claims](https://en.wikipedia.org/wiki/Thundering_herd_problem). This PR brings `bulkSchedule` in line with `bulkEnable` (see elastic#172742): the first task in the batch still runs immediately, but subsequent enabled recurring tasks are scheduled with a randomized `runAt`, evenly distributed up to 5 minutes in the future. Ad-hoc tasks (no `schedule.interval`) and disabled tasks are left untouched and run immediately as before. This also helps unblock upcoming work on `RulesClient.bulkCreate` (elastic#264893), where a single API call may schedule a large number of detection-rule tasks at once. ## Whats included - The existing `randomlyOffsetRunTimestamp()` helper is replaced by a smaller pure helper `addJitter()` that returns `{ runAt, scheduledAt }` - or `undefined` when no interval is supplied - so callers control the spread. - `bulkSchedule` map callback now receives the index `i` and uses `addJitter()` when `enabled && i > 0`. - `bulkEnable`'s behavior continues exactly the same with the `i > 0` branch using the shared `addJitter()` helper. ## How to test > [!IMPORTANT] > There is no easy way to test TM `bulkSchedule()` randomizing without `v2` alerting. Because of this, the test below only covers task randomizing under `bulkEnable()`. If you apply debugging here, you will notice that enabling detection rules in bulk uses `bulkSchedule()` under the hood, but it does so in `enabled: false` state. In other words, no jitter will get applied until the following pass. This is expected, what the test below does primarily is to verify that existing behavior is unaffected. The changes to behavior in `bulkSchedule(enabled:true)` will become more meaningful with upcoming work on alerting `v2` and `RulesClient.bulkCreate`. 1. Start ES + Kibana from this branch. Make sure you have a clean ES with no rules. 2. In Kibana, navigate to **Security → Rules → Detection rules (SIEM)** and click **Add Elastic Rules** to install the prebuilt detection rule set (~1850 rules). Leave them disabled. > Note: This is a good time to place some breakpoints if you're debugging locally. 3. Go back to the rules management screen. Under "Installed Rules" click the checkbox to select first 20 rules then `Bulk actions` > `Enable`. You should see a message saying "Successfully enabled 20 rules" 4. Verify the `runAt` / `scheduledAt` distribution using [`check-task-runtime.sh`](https://github.com/sdesalas/kibana-knowledge/blob/main/scripts/check-task-runtime.sh): ```bash $ ./check-task-runtime.sh ``` Or if you are using ports different to the standard `5601` and `9200` ```bash $ KIBANA_DEV_PORT=5606 ES_DEV_PORT=9205 ./check-task-runtime.sh ``` 5. Expected output: counts match, and the first-20 task timestamps are **spread across several minutes** rather than all stamped with the same "now": ``` starting.. KIBANA_URL=http://localhost:5601/kbn ES_URL=http://localhost:9200 1. 2. 3. 4. 5. 6. rules: 1850 rules_enabled: 20 tasks: 20 tasks_enabled: 20 api_key_owner: 20 apiKey present: 20 first 20 tasks: taskType status enabled runAt scheduledAt alerting:siem.queryRule idle true 2026-05-19T16:20:08.323Z 2026-05-19T16:20:08.323Z alerting:siem.queryRule idle true 2026-05-19T16:21:28.689Z 2026-05-19T16:21:28.689Z alerting:siem.eqlRule idle true 2026-05-19T16:21:05.927Z 2026-05-19T16:21:05.927Z alerting:siem.queryRule idle true 2026-05-19T16:20:53.163Z 2026-05-19T16:20:53.163Z alerting:siem.queryRule idle true 2026-05-19T16:23:30.562Z 2026-05-19T16:23:30.562Z alerting:siem.esqlRule idle true 2026-05-19T16:23:45.295Z 2026-05-19T16:23:45.295Z ... ``` For every task, `runAt` should equal its matching `scheduledAt`. The timestamps should be distributed across the configured jitter window (`min(rule interval, 5m)`) - confirming jitter is applied per-task. On `main` without this PR, every task's `runAt` collapses to the same value. ## Callers of `bulkSchedule` For reference, the production callers of `TaskScheduling.bulkSchedule` and whether they exercise the new jitter: | Caller | What it schedules | Hits the new jitter? | |---|---|---| | [`alerting_v2/.../rules_client.bulkEnableRules`](https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/alerting_v2/server/lib/rules_client/rules_client.ts) | enabled, recurring (`schedule.interval`, `enabled: true`) | **Yes** — primary path exercised by the manual test above | | [`alerting/.../bulk_enable_rules.ts`](https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/alerting/server/application/rule/methods/bulk_enable/bulk_enable_rules.ts) (legacy) | recurring but `enabled: false` — the comment in that file explicitly says "we create the task as disabled, taskManager.bulkEnable will enable them by randomising their schedule datetime" | No (jitter applied later by `bulkEnable`) | | [`workflows_execution_engine/server/plugin.ts`](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/workflows_execution_engine/server/plugin.ts) | enabled but ad-hoc (no `schedule`) | No (ad-hoc — runs immediately, correct) | | [`actions/create_execute_function.ts`](https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/actions/server/create_execute_function.ts) | ad-hoc action tasks | No | | [`actions/create_unsecured_execute_function.ts`](https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/actions/server/create_unsecured_execute_function.ts) | ad-hoc action tasks | No | | [`alerting/.../backfill_client.ts`](https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/alerting/server/backfill_client/backfill_client.ts) | variable is literally `adHocTasksToSchedule` | No | Of these, only the alerting_v2 `bulkEnableRules` path schedules enabled recurring tasks in bulk, so it is the only caller whose runtime behavior changes with this PR. ## Release note skip ## Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### Identify risks - Behavior change is scoped to recurring tasks at `i > 0`; single-task `bulkSchedule` calls and ad-hoc tasks retain the existing "run now" semantics. - The `bulkEnable` path is unchanged in semantics; only the helper signature changed. --------- Co-authored-by: Cursor <cursoragent@cursor.com>

…69991) **Resolves: #195136** **Related to: #264893** **Related to: #269340** ## Summary `TaskScheduling.bulkSchedule` previously sent every task to the store with no `runAt`, which caused the store to default them all to "now". When a caller bulk-scheduled many recurring tasks at once, the polling queue was flooded with [simultaneous claims](https://en.wikipedia.org/wiki/Thundering_herd_problem). This PR brings `bulkSchedule` in line with `bulkEnable` (see #172742): the first task in the batch still runs immediately, but subsequent enabled recurring tasks are scheduled with a randomized `runAt`, evenly distributed up to 5 minutes in the future. Ad-hoc tasks (no `schedule.interval`) and disabled tasks are left untouched and run immediately as before. This also helps unblock upcoming work on `RulesClient.bulkCreate` (#264893), where a single API call may schedule a large number of detection-rule tasks at once. ## Whats included - The existing `randomlyOffsetRunTimestamp()` helper is replaced by a smaller pure helper `addJitter()` that returns `{ runAt, scheduledAt }` - or `undefined` when no interval is supplied - so callers control the spread. - `bulkSchedule` map callback now receives the index `i` and uses `addJitter()` when `enabled && i > 0`. - `bulkEnable`'s behavior continues exactly the same with the `i > 0` branch using the shared `addJitter()` helper. ## How to test > [!IMPORTANT] > There is no easy way to test TM `bulkSchedule()` randomizing without `v2` alerting. Because of this, the test below only covers task randomizing under `bulkEnable()`. If you apply debugging here, you will notice that enabling detection rules in bulk uses `bulkSchedule()` under the hood, but it does so in `enabled: false` state. In other words, no jitter will get applied until the following pass. This is expected, what the test below does primarily is to verify that existing behavior is unaffected. The changes to behavior in `bulkSchedule(enabled:true)` will become more meaningful with upcoming work on alerting `v2` and `RulesClient.bulkCreate`. 1. Start ES + Kibana from this branch. Make sure you have a clean ES with no rules. 2. In Kibana, navigate to **Security → Rules → Detection rules (SIEM)** and click **Add Elastic Rules** to install the prebuilt detection rule set (~1850 rules). Leave them disabled. > Note: This is a good time to place some breakpoints if you're debugging locally. 3. Go back to the rules management screen. Under "Installed Rules" click the checkbox to select first 20 rules then `Bulk actions` > `Enable`. You should see a message saying "Successfully enabled 20 rules" 4. Verify the `runAt` / `scheduledAt` distribution using [`check-task-runtime.sh`](https://github.com/sdesalas/kibana-knowledge/blob/main/scripts/check-task-runtime.sh): ```bash $ ./check-task-runtime.sh ``` Or if you are using ports different to the standard `5601` and `9200` ```bash $ KIBANA_DEV_PORT=5606 ES_DEV_PORT=9205 ./check-task-runtime.sh ``` 5. Expected output: counts match, and the first-20 task timestamps are **spread across several minutes** rather than all stamped with the same "now": ``` starting.. KIBANA_URL=http://localhost:5601/kbn ES_URL=http://localhost:9200 1. 2. 3. 4. 5. 6. rules: 1850 rules_enabled: 20 tasks: 20 tasks_enabled: 20 api_key_owner: 20 apiKey present: 20 first 20 tasks: taskType status enabled runAt scheduledAt alerting:siem.queryRule idle true 2026-05-19T16:20:08.323Z 2026-05-19T16:20:08.323Z alerting:siem.queryRule idle true 2026-05-19T16:21:28.689Z 2026-05-19T16:21:28.689Z alerting:siem.eqlRule idle true 2026-05-19T16:21:05.927Z 2026-05-19T16:21:05.927Z alerting:siem.queryRule idle true 2026-05-19T16:20:53.163Z 2026-05-19T16:20:53.163Z alerting:siem.queryRule idle true 2026-05-19T16:23:30.562Z 2026-05-19T16:23:30.562Z alerting:siem.esqlRule idle true 2026-05-19T16:23:45.295Z 2026-05-19T16:23:45.295Z ... ``` For every task, `runAt` should equal its matching `scheduledAt`. The timestamps should be distributed across the configured jitter window (`min(rule interval, 5m)`) - confirming jitter is applied per-task. On `main` without this PR, every task's `runAt` collapses to the same value. ## Callers of `bulkSchedule` For reference, the production callers of `TaskScheduling.bulkSchedule` and whether they exercise the new jitter: | Caller | What it schedules | Hits the new jitter? | |---|---|---| | [`alerting_v2/.../rules_client.bulkEnableRules`](https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/alerting_v2/server/lib/rules_client/rules_client.ts) | enabled, recurring (`schedule.interval`, `enabled: true`) | **Yes** — primary path exercised by the manual test above | | [`alerting/.../bulk_enable_rules.ts`](https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/alerting/server/application/rule/methods/bulk_enable/bulk_enable_rules.ts) (legacy) | recurring but `enabled: false` — the comment in that file explicitly says "we create the task as disabled, taskManager.bulkEnable will enable them by randomising their schedule datetime" | No (jitter applied later by `bulkEnable`) | | [`workflows_execution_engine/server/plugin.ts`](https://github.com/elastic/kibana/blob/main/src/platform/plugins/shared/workflows_execution_engine/server/plugin.ts) | enabled but ad-hoc (no `schedule`) | No (ad-hoc — runs immediately, correct) | | [`actions/create_execute_function.ts`](https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/actions/server/create_execute_function.ts) | ad-hoc action tasks | No | | [`actions/create_unsecured_execute_function.ts`](https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/actions/server/create_unsecured_execute_function.ts) | ad-hoc action tasks | No | | [`alerting/.../backfill_client.ts`](https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/alerting/server/backfill_client/backfill_client.ts) | variable is literally `adHocTasksToSchedule` | No | Of these, only the alerting_v2 `bulkEnableRules` path schedules enabled recurring tasks in bulk, so it is the only caller whose runtime behavior changes with this PR. ## Release note skip ## Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios ### Identify risks - Behavior change is scoped to recurring tasks at `i > 0`; single-task `bulkSchedule` calls and ad-hoc tasks retain the existing "run now" semantics. - The `bulkEnable` path is unchanged in semantics; only the helper signature changed. --------- Co-authored-by: Cursor <cursoragent@cursor.com>

sdesalas self-assigned this May 19, 2026

sdesalas force-pushed the issue-195136-randomize-task-schedules branch from fba596b to 7cde863 Compare May 20, 2026 08:24

sdesalas marked this pull request as ready for review May 20, 2026 10:12

sdesalas requested a review from a team as a code owner May 20, 2026 10:12

sdesalas mentioned this pull request May 20, 2026

[Security Solution][Alerting] Add rulesClient.bulkCreate(), with feedback from ResponseOps #269340

Open

darnautov self-requested a review May 20, 2026 13:49

darnautov approved these changes May 20, 2026

View reviewed changes

sdesalas added 3 commits May 20, 2026 17:57

bulkSchedule explicitlly sets scheduling on first task like bulkEnable

08379a0

Add comment for why ad-hoc tasks run immediately

f3d3e0a

Adhoc tasks run immediately. Make it explicit.

ae89883

sdesalas merged commit 6669b2a into elastic:main May 21, 2026
34 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Security Solution] Randomize task schedules when bulk scheduling#269991

[Security Solution] Randomize task schedules when bulk scheduling#269991
sdesalas merged 4 commits into
elastic:mainfrom
sdesalas:issue-195136-randomize-task-schedules

sdesalas commented May 19, 2026 •

edited

Loading

Uh oh!

infra-vault-gh-plugin-prod Bot commented May 20, 2026

Uh oh!

infra-vault-gh-plugin-prod Bot commented May 20, 2026

Uh oh!

infra-vault-gh-plugin-prod Bot commented May 20, 2026

Uh oh!

infra-vault-gh-plugin-prod Bot commented May 20, 2026

Uh oh!

darnautov left a comment

Uh oh!

darnautov May 20, 2026

Uh oh!

sdesalas May 20, 2026

Uh oh!

darnautov May 20, 2026

Uh oh!

sdesalas May 20, 2026

Uh oh!

sdesalas May 20, 2026

Uh oh!

kibanamachine commented May 20, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

sdesalas commented May 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Whats included

How to test

Callers of bulkSchedule

Release note

Checklist

Identify risks

Uh oh!

infra-vault-gh-plugin-prod Bot commented May 20, 2026

Uh oh!

infra-vault-gh-plugin-prod Bot commented May 20, 2026

Uh oh!

infra-vault-gh-plugin-prod Bot commented May 20, 2026

Uh oh!

infra-vault-gh-plugin-prod Bot commented May 20, 2026

Uh oh!

darnautov left a comment

Choose a reason for hiding this comment

Uh oh!

darnautov May 20, 2026

Choose a reason for hiding this comment

Uh oh!

sdesalas May 20, 2026

Choose a reason for hiding this comment

Uh oh!

darnautov May 20, 2026

Choose a reason for hiding this comment

Uh oh!

sdesalas May 20, 2026

Choose a reason for hiding this comment

Uh oh!

sdesalas May 20, 2026

Choose a reason for hiding this comment

Uh oh!

kibanamachine commented May 20, 2026

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

Metrics [docs]

History

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

sdesalas commented May 19, 2026 •

edited

Loading

Callers of `bulkSchedule`